The design of complex hardware systems involves a combination of creating new hardware sub-designs (e.g., portions of a proprietary hardware design code and supporting documentation) from scratch and purchasing hardware sub-designs that are prepared by an IP block owner. In many cases, a designer purchases hardware sub-designs from an IP block owner (e.g., organizations/persons which own the intellectual property rights to hardware sub-designs) rather than develop a particular hardware sub-design internally. IP block owners face several challenges in licensing and maintaining control of their intellectual property (e.g., hardware sub-designs). One of the biggest challenges is the unauthorized use of and lack of effective ways of licensing hardware sub-designs on a per use basis. Unfortunately, FPGAs (field-programmable gate arrays) and ASICs (application specific integrated circuits) do not have any trusted and fixed unique identifiers, and as a result hardware sub-designs cannot be easily be licensed on a per use basis. (e.g., a per use license would require an accounting of every device a particular hardware sub-design is implemented on, and a lack of trusted unique identifiers makes it difficult to peg a particular license to a particular FPGA). Instead, IP block owners must often sell global one-time licenses (e.g., a global one-time license to use a particular hardware sub-design on any and all FPGAs at a designer) unless the IP block owner trusts (e.g., through a long standing business relationship) that a designer will properly account for and pay for each use of the hardware sub-design. Furthermore, rampant theft pervades the industry because of a lack of ways to track where hardware sub-designs are copied and applied (e.g., once a hardware sub-design is sold, an IP block owner is unable to monitor and determine how many instances of a particular hardware sub-design were made on FPGAs). Thus, IP block owners are unable to maximize their leverage of intellectual property rights in hardware sub-designs, and are unable to control where their hardware sub-designs are ultimately utilized.
FIG. 1A illustrates a FPGA 118 having a plurality of IP blocks 110A-110I. The FPGA 118 is coupled to designer 111 through bus 108. A designer 111 (e.g., a person or company who is creating a hardware system) transfers hardware sub-designs (e.g., the designer 111 may reuse a particular hardware sub-design that was previous created by the designer 111, may develop a custom design, may use a design in the public domain, or may use a design purchased from or created by a third party IP block owner) to the FPGA 118 through bus 108 (e.g., the designer 111 may transfer a representation of the design to the FPGA 118 to program one or more IP blocks 110A-110I and/or the designer's logic 150).
The FPGA 118 includes a designer's logic 150 and a plurality of IP blocks 110A-1101. The designer's logic 150 includes hardware sub-designs that have been created by a designer 111. Each IP block 110A-110I within FPGA 118 includes a hardware sub-design that has been purchased from a third-party. (e.g., the hardware sub-design within a particular IP block 110A may be purchased from a third party IP block owner 100 as illustrated in FIG. 1B for example).
FIG. 1B shows a prior art transaction flow diagram between a designer 111, IP block owner 100, and FPGA provider 120 for the implementation of a design. In FIG. 1B, a designer 111 communicates first with the FPGA provider 120 as illustrated in circled 1. The communication, circled 1, may be a request to purchase a FPGA device 118 from the FPGA provider 120 (e.g., the FPGA provider may be any commercial supplier of FPGAs such as a distributor, retailer, manufacturer, and/or wholesaler). The FPGA provider 120 then ships to the designer 111 a FPGA 118 in circled 2. (e.g., the FPGA provider 120 may perform a credit check, generate an invoice, and accept an offer as part of a business transaction between designer 111 and FPGA provider 120).
After the designer 111 receives the FPGA 118 from the FPGA provider 120 in circled 2, the designer 111 sends a request to an IP block owner 100 to purchase a proprietary hardware sub-design that the designer 111 requires to complete his hardware system in circled 3. (e.g., an IP block owner 100 may have ownership rights in the proprietary hardware sub-design that the designer 111 needs to complete his hardware system within the time and cost constraints afforded to him). After the designer 111 provides a request to the IP block owner 100 in circled 3 (e.g., the designer 111 may electronically send to the IP block owner 100 an offer to purchase the proprietary hardware sub-design in the form of a purchase order or may telephone the IP block owner 100 to purchase the proprietary hardware sub-design), the IP block owner 100 provides the proprietary hardware sub-design to the designer 111 in circled 4 (e.g., the IP block owner 100 may enter into a contract for a global license and provide the HDL and/or RTL implementation design details and corresponding documentation necessary to implement the proprietary hardware sub-design to the designer 111 after accepting the designer 111's offer to purchase a global intellectual property license for the proprietary hardware sub-design owned by the IP block owner 100).
The designer 111 then incorporates the proprietary hardware sub-design received from IP block owner 100 into the FPGA 118 (e.g., the designer 111 may program the FPGA 118 which has been purchased by the designer 111 from the FPGA provider 120 through the bus 108 as described previously in FIG. 1A). Unfortunately, the IP block owner 100 loses control over his intellectual property after the proprietary hardware sub-design details are sent to the designer 111. Even if the IP block owner 100 encrypts a portion of their proprietary hardware sub-design, the designer 111 can freely replicate and utilize it for as many FPGAs 118 as he/she desires (e.g., by replicating the license code in addition to the encrypted circuit). Furthermore, the IP block owner 100 is unable to determine whether the designer 111 has misappropriated the proprietary hardware sub-design that the IP block owner 100 has provided and is unable to monitor whether the designer 111 has resold the proprietary hardware sub-design to others (e.g., the IP block owner 100 may have invested millions of dollars in the original design of his proprietary hardware sub-design, and may have difficulty in recouping his investment but for misappropriation and/or theft of the proprietary hardware sub-design by the designer 111 because the IP block owner 100 is unable to license his intellectual property to others). Thus, it can be seen that it is desired to provide an improved apparatus and method for protecting proprietary hardware sub-designs created by IP block owners.